The present invention relates to field of data transfer technology and input/output (I/O) processing. More specifically, the present invention relates to a method, apparatus, and system for maintaining a conflict-free private memory address space for I/O subsystems through a dynamic data flow architecture.
Presently, computer systems employ a wide variety of peripheral components or input/output (I/O) devices. For example, a typical computer system usually contains a monitor, a keyboard, a mouse, a floppy drive, a network controller, a disk drive or an array of disk drives, and optionally, a printer. High performance computer systems such as servers have more complex I/O device requirements.
Typically, a host processor of the computer system loads a software driver for each of the devices that the computer system supports. These drivers are loaded into the memory of the system host processor and address space must be allocated to these devices. In addition, in operation, these devices generate interrupts that contend for the processing time of the host processor.
Generally, intelligent I/O systems, such as redundant array of independent disks (RAID) technology, RAID add-in cards, RAID on motherboard implementations (RAID I/O Subsystems) or other I/O technology based on an I/O Processor (IOP), such as those available from the Intel Corporation, contain a local memory subsystem provided by the IOP by means of an integrated memory controller unit and the physical memory itself. The memory is used by the embedded RAID application software running on the IOP. Some of this memory is typically used to provide caching functions for data in either upstream or downstream directions. For example, the caching of data can increase write performance by providing the host with immediate completion replies of write operations while holding onto that operation""s data in local memory until such time as it is passed to the I/O interconnect device for processing. While this invention can apply to other I/O technologies, RAID will be the example used herein for the purposes of illustrations and explanations.
Generally, a typical RAID I/O subsystem includes a primary PCI bus that is connected to a host bus and a secondary PCI bus that is connected to an I/O interconnect. Placing the I/O interconnect device on the secondary bus allows the RAID firmware to xe2x80x9chidexe2x80x9d the I/O interconnect device from the host so that the host does not attempt to configure and control the device. Because the host no longer configures the I/O interconnect device, the RAID I/O subsystem is responsible for allocating any PCI memory address space requirements to the I/O interconnect device. This particular requirement is also referred to herein as requirement # or need #1 for private memory where private memory is now defined as address spaces for use exclusively by the RAID I/O subsystem without interference with normal host operations. Another requirement (also referred to as requirement #2 or need #2 herein) for private memory arises from the physical location of the I/O interconnect device and the requirement of RAID I/O subsystem to utilize its local memory subsystem for caching purposes. In order for the I/O interconnect device to bus master data from the IOP""s local memory subsystem to its storage devices, or vice-versa, it utilizes the secondary PCI bus provided by the IOP and access the local memory subsystem through, in the case of an IOP, a secondary Address Translation Unit (SATU), which is also a PCI device requiring PCI memory address space. Both of these needs require that neither the I/O interconnect device or the SATU address range interfere with normal host operations.
Typical IOPs provide a mechanism for isolating addresses between the I/O interconnect device and the IOP by means of registers within the integrated PCIxe2x80x94PCI bridge that can be programmed to prevent the forwarding of a specified range of addresses upstream. This is not, however, a complete solution because it does not guarantee that the I/O interconnect device or SATU address ranges chosen will not potentially conflict with the memory range that a particular host request has specified for its reply buffer (e.g., location where the host has requested the RAID I/O subsystem read or write data into system memory). One known method for insuring that the SATU address range chosen will not potentially conflict with a host reply buffer is to program the Primary Address Translation Unit (PATU) to a range sufficiently large enough to represent the amount of local memory desirable for use by caching between the RAID core and the I/O interconnect via the SATU. This method is inefficient because (a) the PATU does not need this much address space, it is wasting addresses in the host memory space that might be needed by other adapter cards or internal operating system structures such as Page Table Entries and (b) many operating systems have a limit of 64 megabytes of addresses that they will allocate to a single device thus limiting the amount of local memory available to a RAID I/O subsystem to 64 MB where the IOP itself may have a limit of up to 1 gigabyte or more.